1. Technical Field of the Invention
The present invention generally relates to embedded systems. More particularly, the present invention is directed to an embedded system and method for performing a background code update by utilizing firmware update routines from an incoming code image and task switching capabilities, i.e., task switching function, from an executing code image.
2. Description of the Prior Art
An embedded system is a specialized computer system, including both hardware and software, which forms a part of a larger system or machine. Furthermore, the larger system or machine may have a plurality of embedded systems. Typically, each of the embedded systems is housed on single microprocessor board with firmware (i.e., software) stored as object code within a non-volatile memory device, such as a programmable read only memory (i.e., “PROM”). The larger system or machine that generally utilizes the embedded system may include a wide variety of systems, ranging from modems, to mid-range computing devices and enterprise systems, to storage automation libraries, to digital satellite receivers, and the like. The embedded systems commonly utilize firmware that provides an operating system enabling multitasking, which simplifies a process of performing a plurality of actions with a single microprocessor. With multitasking, the microprocessor is utilized more efficiently because the idle time associated with performing one action may be utilized for performing another action. For example, a servo control function may be waiting for a interval to elapse (i.e., via a timer) before checking position control parameters of a robotic component of the larger system or machine. While waiting for the timer to expire, the microprocessor may send or receive small computer system interface (i.e., “SCSI”) data through another function. These actions are often called processes, threads, tasks, or process threads. Hereinafter, the foregoing actions will be referred to as process threads for simplicity and clarity.
The act of switching between the process threads is called task switching. Task switching based on each process thread voluntarily giving up microprocessor time is commonly referred to as “round robin” task switching. Alternatively, task switching resulting from a resource becoming available or from a function call to signal another process thread (e.g., via sending a message between the two process threads) is commonly referred to as “event driven” task switching. Moreover, task switching based on periodically switching microprocessor control between process threads via a timer or some other trigger is commonly referred to as “time slice” task switching. Additionally, combinations of the foregoing task switching options may be utilized in a particular embedded system. From among the foregoing options, the time slice task switching option tends to be less efficient because a task switch may occur at times other than idle times, thereby wasting processing resources (i.e., unnecessary task switching consumes microprocessor bandwidth). Additionally, time slice task switching is generally more complicated to set up and can create a variety of problems.
Typically, an embedded system provides for a code update process to support new features or to fix problems in the firmware (i.e., firmware upgrade). In many cases, the firmware upgrade will take the larger system or machine—of which the embedded system forms a part—out of service for some period of time during which the firmware upgrade is performed. For the systems which are utilized for critical applications or which are utilized a high percentage of time, it is advantageous to provide a background code update that does not take the larger system out of service. Background updates to the firmware are known in the art. One way the background code update may be achieved is by executing the system code out of memory devices other than those being upgrade. For example, a system firmware that needs to be updated may reside in a programmable read-only memory (i.e., “PROM”) prior to power-up. The system firmware stored on the PROM may be copied to a random access memory (i.e., “RAM”) during a power-on sequence and subsequently executed in the RAM. Thus, the system firmware on the PROM may be updated because the current system firmware is executed from the RAM. This is of critical importance because many nonvolatile devices cannot be updated while in use. In addition, overwriting currently executing firmware may result in unpredictable consequences. Therefore, by executing firmware from a separate memory device, a code update to the firmware may occur while the system operates normally utilizing one or more other process threads of the firmware, thereby accomplishing a background code update to the firmware.
Utilizing code update routines from the firmware update itself has associated advantages. A first advantage obtained by utilizing code update routines from the firmware update is elimination of the need to test a newer firmware update against every previous version of firmware that may be present in the field. That is, without utilizing the code update routines from the firmware update, firmware update compatibility between the previous version of the firmware and the newer firmware version may be uncertain and must be tested before attempting an upgrade at a customer site. A further advantage is the whole structure of the previous version of firmware, in PROM, can be updated without any special interim firmware updates at the customer site. For example, the previous firmware installed at the customer site may support a single copy of the firmware in the PROM, while the new version of the firmware may support a boot sector and two copies of the firmware. The update of the previous version of the firmware to the advanced new version that supports the boot sector and the two code copies of the firmware would normally require an intermediate (i.e., “special”) code load that would prepare the embedded system for the firmware update because the previous firmware's code update routines have no prior knowledge about the boot sector and the two copies of the new firmware version. If a firmware update were attempted without the special code load, the embedded system and even the larger system of which the embedded system being updated forms a part may become inoperative. However, the code update routines of the firmware update know all about the details of the firmware update because these routines are part of the new firmware that supports a boot sector and two copies of the firmware. That is, the location of the firmware update routines is provided as part of the new firmware update. The location of the code update routines may be implied as a fixed offset in the new firmware update, or it may be provided as a pointer within the new firmware update. In addition, the code update routines may have a fixed execution point or a variable one. More particularly, 1) the code update routines may be compiled for execution from a particular location in the memory, such that the code update routines are always copied to the particular location in the memory before execution begins; or alternatively 2) the code update routines may be, and usually are, compiled as position independent code, so that they can be executed from any location within memory.
Notwithstanding the foregoing, there exists a problem with executing firmware update routines out of the firmware update. The problem is that function calls cannot be made outside the scope of the firmware update. For example, if the code update routines attempt to call a task switching function that is outside the scope of the update routines, unpredictable results may occur. That is, in order to invoke the task switching function, the new code update routines have to reference a memory map that is disparate from a current memory map associated with the new firmware. For example, assume the first alternative in which the new firmware update is compiled to execute at a base-starting hexadecimal address of 0x0C000000, which happens to be the address of the previous firmware's base-starting execution address after a reset and a copy to RAM. But, the temporary location of the new firmware update will be another hexadecimal address outside the scope of the previous firmware, such as OxOC100000, because the new firmware update is being received and cannot interfere with or be copied over the previous, currently executing, firmware. Any external address references that the new firmware update routines make will be based on the OxOC000000 starting hexadecimal address of the new compiled firmware update of which they are a part, but there is no telling what code alignment actually will reside in that space because it contains a version that is different from the previous, currently executing firmware. That is, elements within the new complied firmware update may not reside in the same relative position as like elements in the previous firmware, i.e., code in the new firmware update may be shifted either up or down with respect to the previous firmware.
Now assume the second alternative in which the firmware update is compiled as position independent code. This alternative creates different problems. For example, some microprocessors and compilers do not support position independent code. Additionally, with position independent code, external references are addressed as relative offsets. Therefore, although the new code update routines may include a task switching function, the task switching function will have external references to data and code areas, thereby creating problems described hereinabove with regard to the first alternative. For example, a task switching function may be located at hexadecimal address 0x0C080000 of the currently executing firmware. The same task switching function may be located at hexadecimal address 0x0C180340 of the new firmware. An attempt, by the new firmware update routines, to call the task switching function will result in a call to the hexadecimal address 0x0C180340. While this address is an accurate location of the task switching function of the new firmware, it may contain references to other memory locations such as a process thread state table. Such references may produce the same unpredictability as described in the previous example because the task switching function at hexadecimal address 0x0C080000 is based on another version of the firmware with potentially different address locations or offsets. That is, if the new firmware update is compiled as position independent code, then the task switching function from the new firmware update will attempt to access un-initialized code from the new firmware update. If the new firmware update image is compiled for direct addressing of the code, then the task switching function from the new firmware update image will experience the same potential offset problem described in the first alternative. Finally, a change to the task switching function could have unpredictable results if it were to attempt access to a data area initialized by the task switching function that used different data structures.
Therefore there is a need in the art of a system and method for providing a background code update that overcomes the above-identified problems associated with the prior art firmware updates. More particularly, there is a need to provide an embedded system and method that utilizes firmware update routines from the incoming firmware image while utilizing task switching capabilities, i.e., task switching function, from the executing firmware image.